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Commissioner for Patents 
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Alexandria, VA 22313-1450 

Sir: 

A Notice of Non-Compliant Appeal Brief was received by Applicant stating that the appeal 
brief filed on July 12, 2006 is considered non-compliant because it fails to give a concise 
explanation of the subject matter defined in each independent claims (12 and 21); that each ground 
of rejection presented for review should include citations of statutes, regulations and authorities; 
and each ground of rejection should be treated under a separate heading. A copy of the Notice of 
Non-Compliant Appeal Brief is attached hereto. 

No fees are believed to be required. If, however, any fees are required, I authorize the 
Commissioner to charge these fees which may be required to IBM Corporation Deposit Account 
No. 09-0447. No extension of time is believed to be necessary. If, however, an extension of time is 
required, the extension is requested, and I authorize the Commissioner to charge any fees for this 
extension to IBM Corporation Deposit Account No. 09-0447. 
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REAL PARTY IN INTEREST 



The real party in interest in this appeal is the following party: International Business Machines 
Corporation of Armonk, N.Y. 
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RELATED APPEALS AND INTERFERENCES 



With respect to other appeals or interferences that will directly affect, or be directly affected 
by, or have a bearing on the Board's decision in the pending appeal, there are no such appeals or 
interferences. 
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STATUS OF CLAIMS 



A. TOTAL NUMBER OF CLAIMS IN APPLICATION 

Claims in the application are: 1-29 

B. STATUS OF ALL THE CLAIMS IN APPLICATION 

1. Claims canceled: none 

2. Claims withdrawn from consideration but not canceled: none 

3. Claims pending: 1-29 

4. Claims allowed: none 

5. Claims rejected: 1-29 

6. Claims objected to: none 

C. CLAIMS ON APPEAL 

The claims on appeal are: 1-29 
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STATUS OF AMENDMENTS 

No amendment after final rejection was filed for this case. 
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SUMMARY OF CLAIMED SUBJECT MATTER 



A. CLAIM 1 - INDEPENDENT 

Storage devices are widely used in computer systems to store data. In order to manage 
these storage devices, several disk management techniques are currently available. One useful 
and popular technique is logical volume management. Instead of interfacing directly with a 
physical partition on the storage device, a logical volume manager (LVM) divides the disk space 
on the drive into logical partitions. A logical partition may include several storage devices but is 
transparent to a user. In other words, the logical partition appears as a single storage device to 
the user. 

At the lowest level of logical volume management is the physical storage device itself. 
Each individual storage device is formatted into a physical volume for use by the LVM. Each 
physical volume has a name and belongs to a volume group. A volume group is a collection of 
storage devices under the management of the LVM that are treated as a single large storage area. 
Each volume group defines one or more logical volumes. Logical volumes are groups of 
information located on physical volumes. Although data on a physical volume can be 
discontinuous, the data on a logical volume appears to the user as contiguous. This arrangement 
permits file systems, paging space and other logical volumes to be resized or relocated, span 
multiple physical volumes and have their contents replicated for greater flexibility and 
availability in data storage. 

Multiple logical volumes can be created for each volume group. Creating a logical 
volume requires certain information to be entered into the logical volume manager. For example, 
the LVM requires that each new logical volume have a specified file system type. The specified 
file system type is stored in the logical volume control block (LVCB), which includes in-band 
data (data located within the logical volume) of the LVM. The logical volume control block is 
the first 512 bytes of a logical volume. The LVCB contains information such as the creation date 
of the logical volume, information about mirrored copies, and possible mount points in the 
journal ed file system. Once a logical volume is created, the device type or subtype specified for 
the particular logical volume cannot be changed for the life of the logical volume. 
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Although the LVM allows storage drive space to be added or expanded while the system 
is running, applications have traditionally skipped over the LVCB area when laying down data. 
Applications exclude the LVCB area when writing data in order to retain the configuration 
information contained within the LVCB. However, the configuration information stored in the 
LVCB may not be critical information and may be overwritten without negatively affecting the 
LVM. 

One problem with excluding the LVCB from being written over is that skipping over the 
LVCB area causes alignment problems with the underlying physical storage. Another problem 
with preventing the overwriting of the LVCB is that the application does not know where to start 
laying down its own data. For example, if the LVCB data is to be retained in the first 4K of the 
logical volume and the LVCB needs to be updated to reflect a move in data storage from one 
location to another, the offset for the logical volume will be set to zero in order to allow the 
application to write over the LVCB. Since the application traditionally skips the LVCB area, 
having the offset switched to zero and writing over the LVCB data will cause the application to 
think that its data is corrupted. 

Thus, it would be advantageous to have a technique for allowing the specification of a 
new device type and device subtype to indicate to an application that the application does not 
need to skip over the LVCB. It would also be advantageous to have a technique for using the 
new alternate device type and subtype to signal to an application to behave in a new way. 
Moreover, it would be advantageous to allow an application to supply a new alternate device type 
or subtype in order to manage and control behavioral changes via the device type or subtype. 

Generally speaking, Claim 1 is directed to a technique in a data storage system for 
configuring a new device type or device subtype of a logical volume to allow an application to 
control behavior changes via such new device type/subtype. 

Specifically, Claim 1 is directed to a method for controlling the behavior of an application 
when storing data using a logical volume manager. A logical volume is created. A new device 
type for the logical volume is set, where the new device type is added to a metadata within the 
logical volume manager. A new device with the new device type is added to a kernel space 
(Specification page 16, line 2 - page 17, line 6; Figure 5, all blocks). These alternate device 
types and subtypes advantageously provide a signal to an application that the application can 
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behave in a new way defined by the device type and subtype (Specification page 17, first full 
paragraph). 



B. CLAIM 11 - INDEPENDENT 

Claim 1 1 is directed to a system for controlling the behavior of an application when 
storing data using a logical volume manager. The system comprises a logical volume, a new 
device type set for the logical volume, and an application, where the new device type set for the 
logical volume is used to indicate to the application that the application may perform a particular 
behavior defined by the new device type (Specification page 18, lines 6-28; Figure 7, all blocks). 

Claim 1 1 thus advantageously provides a technique for using the new alternate device 
type and subtype to signal to an application to behave in a new way. 

C. CLAIM 12 - INDEPENDENT and MEANS-PLUS-FUNCTION 

C.l Claim 12 is directed to a data processing system for controlling the behavior of an 
application when storing data using a logical volume manager. The data processing system 
comprises a means for creating a logical volume. The data processing system also comprises a 
means for setting a new device type for the logical volume that was created, where the new 
device type is added to a metadata within the logical volume manager. The data processing 
system also comprises a means for adding a new device with this new device type to a kernel 
space (Specification page 16, line 2 - page 17, line 6; Figure 5, all blocks; Figure 1, blocks 104, 
108, 110 or 112). 

These alternate device types and subtypes advantageously provide a signal to an 
application that the application can behave in a new way defined by the device type and subtype 
(Specification page 17, first full paragraph). 

C.2 Claim 12 is a means-plus-function claim, and the structure corresponding to each of the 
recited means for elements (creating means, setting means and adding means) is shown in Figure 
1, blocks 104, 108, 110 or 112. 

Page 8 of 35 
McBrearty- 10/674,976 



D. CLAIM 21 -INDEPENDENT 

Claim 21 is directed to computer program product tangibly embodied in a tangible 
computer readable medium for controlling the behavior of an application when storing data using 
a logical volume manager. This computer program product includes instructions for creating a 
logical volume. This computer program product also includes second instructions for setting a 
new device type for the logical volume, including adding the new device type to a metadata 
within the logical volume manager. This computer program product also includes instructions 
for adding a new device with the new device type to a kernel space (Specification page 16, line 2 
- page 17, line 6; Figure 5, all blocks). 

These alternate device types and subtypes advantageously provide a signal to an 
application that the application can behave in a new way defined by the device type and subtype 
(Specification page 17, first full paragraph). 
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GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



A. GROUND OF REJECTION 1 (Claims 21-29) 

Whether Claims 21-29 are non-statutory under 35 U.S.C. § 101. 

B. GROUND OF REJECTION 2 (Claim 1) 

Whether Claim 1 fails to comply with the written description requirement of 35 U.S.C. § 
112, first paragraph. 

C. GROUND OF REJECTION 3 (Claims 1-3, 6-14, and 16-20) 

Whether Claims 1-3, 6-14 and 16-20 are obvious over McMichael et al. (US Pub 
2003/0023826) in view of Gao (US Pub 2003/0163578) under 35 U.S.C. § 103. 

D. GROUND OF REJECTION 4 (Claims 4-5 and 15) 

Whether Claims 4-5 and 15 are obvious over McMichael et al. (US Pub 2003/0023826) in 
view of Gao (US Pub 2003/0163578) and further in view of Irwin, Jr. et al. (US 556633 1) under 35 
U.S.C. § 103. 
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ARGUMENT 



As an initial matter, it should be noted that the Examiner's Objection to the Specification 
in the Final Office Action dated January 31, 2006 was already dealt with in a Supplemental 
Response to Office Action filed by Appellants on January 24, 2006, where the Specification was 
amended to delete an objectionable term of 'manager' on page 6 and 18 of the Specification. 

A. GROUND OF REJECTION 1 (Claims 21-29) 

A. l. Claims 21-29 

In originally rejecting Claims 21-29, the Examiner stated that such claims are directed to 
non-statutory subject matter as not being limited to tangible embodiments. In response thereto, 
Appellants amended Claim 21 to specifically recite a tangible medium such that Claim 21 (and 
dependent Claims 22-29) is limited to tangible embodiments. The Examiner now states in 
rejecting these same Claims 21-29 that the computer readable medium is non-statutory. 
Appellants assert that since Claim 21 specifically recites that the computer program product is 
tangibly embodied in a tangible computer readable medium, such claim is in fact statutory under 
35 USC § 101, per MPEP 2106 including MPEP2106 (IV)(B)(l)(a)'. Thus, Claims 21-29 have 
been erroneously rejected under 35 USC § 101. 

B. GROUND OF REJECTION 2 (Claim 1) 
B.l. Claim 1 

With respect to Claim 1, the Examiner has prematurely finally rejected such claim as a 
new ground of rejection (35 USC 112, first paragraph) was made in the most recent Office 
Action (dated January 31, 2006) with respect to Claim 1, and this new ground of rejection was 
not necessitated by Appellants' amendment to Claim 1 (as Claim 1 has never been amended), 
MPEP 706.07(a). 



1 A claimed computer-readable medium encoded with a data structure defines structural and functional 
interrelationships between the data structure and the computer software and hardware components which permit the 
data structure's functionality to be realized, and is thus statutory. 
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According to this premature final rejection of Claim 1 under 35 USC 1 12, first paragraph, 
the Examiner asserts that the Specification fails to describe the claimed step of setting a new 
device type for the logical volume, wherein the new device type is added to a metadata within the 
logical volume manager. Appellants urge that this step is in fact described and enabled in the 
Specification at page 16, lines 26-29, which describes operations performed by the Logical 
Volume Manager, including a statement that "the logical volume manager adds the new device 
type to the metadata (step 508)", such operational step also being depicted in Figure 5, block 508. 
This logical volume manager (LVM) metadata could not be the same metadata as the LVCB 
metadata described in the Specification at page 6 (in the Summary of the Invention) as one of the 
expressed purposes of the present invention is to allow the overwriting of the LVCB metadata in 
certain circumstances. If the LVM metadata (where the new device type is stored, per Claim 1) 
were the same as the LVCB metadata, then when the LVCB metadata were overwritten during 
such certain circumstances, the new device type would be overwritten and the system would no 
longer be operable as the device types for the storage devices would no longer exist, as would 
have been recognized to those of ordinary skill in the art. The purpose of [the enablement] 
provision is to assure that the inventor provides sufficient information about the claimed 
invention that a person of skill in the field of the invention can make and use it without undue 
experimentation, relying on the patent specification and the knowledge in the art, Scripps Clinic 
& Research Foundation v. Genentech, Inc., 927 F.2d 1565, 18 USPQ2d 1896 (Fed. Cir. 1991). 
As described above, the burden has been met. Thus, when the Specification is considered as a 
whole, it would have been understood by those of ordinary skill in the art that the metadata used 
to maintain new device types is metadata associated with the Logical Volume Manager (LVM), 
as expressly recited in Claim 1 and described in the Specification on page 16, lines 26-29 and 
depicted in Figure 5, block 508. 

It should also be noted that the claims as originally filed are considered a part of the 
Specification disclosure, and Claims 1,12 and 21 as originally filed all described that the new 
device type is added to a metadata within the logical volume manager, and thus the requirements 
for complying with 35 USC 1 12, 1 st paragraph, as detailed in MPEP 2163(1) et seq., have been 
met. 
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It is thus urged that Claim 1 has been erroneously rejected under 35 USC 1 12, first 
paragraph, as the Specification as originally filed described - in numerous locations and as 
depicted in the figures and claimed in the originally filed claims - that the new device type is 
added to a metadata within the logical volume manager. 

C. GROUND OF REJECTION 3 (Claims 1-3, 6-14, and 16-20) 

C.l. Claims 1 and 12 

In rejecting claims under 35 U.S.C. Section 103, the examiner bears the initial burden of 
presenting a prima facie case of obviousness. In re Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 
1443, 1444 (Fed. Cir. 1992). Only if that burden is met, does the burden of coming forward with 
evidence or argument shift to the applicant. Id. To establish prima facie obviousness of a 
claimed invention, all of the claim limitations must be taught or suggested by the prior art. 
MPEP 2143.03 (emphasis added by Applicants). See also, In re Royka, 490 F.2d 580 (C.C.P.A. 
1974). If the examiner fails to establish a prima facie case, the rejection is improper and will be 
overturned. In re Fine, 837 F.2d 1071, 1074, 5 USPQ2d 1596, 1598 (Fed. Cir. 1988). In the 
absence of a proper prima facie case of obviousness, an applicant who complies with the other 
statutory requirements is entitled to a patent. See In re Oetiker, 977 F.2d 1443, 1445, 24 USPQ2d 
1443, 1444 (Fed. Cir. 1992). 

With respect to Claim 1, it is urged that none of the cited references teach or suggest the 
claimed feature of "setting a new device type for the logical volume, wherein the new device type 
is added to a metadata within the logical volume manager 1 '' (emphasis added by Appellants). As 
can be seen, the new device type (for the logical volume) is added to a metadata within the 
logical volume manager, thereby advantageously providing a mechanism for allowing the device 
type specified during creation of the logical volume to signal to an application that the 
application can perform a particular behavior (Specification page 16, bottom paragraph - page 
17, middle paragraph; page 18, last paragraph - page 19, first paragraph). In rejecting this aspect 
of Claim 1, the Examiner cites McMichael's teaching at page 6, paragraphs 60-62 as teaching 
this claimed feature. Appellants urge that while these cited passages make mention of 
enumerating a volume device object for a logical volume, these volume device objects are stored 
by the object manager 407 in the device hierarchy by their device names (page 6, paragraph 
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0060, next to last sentence). This object manager 407 can also be seen at McMichael's Figure 4, 
element 407 (bottom of the figure). This object manager is separate and distinct from 
McMichael's volume managers (volume managerl 411 and volume manager2 412), and thus this 
teaching by McMichael of storing of volume device objects by the object manager does not teach 
or otherwise suggest adding the new device type to a metadata within the logical volume 
manager, as the object manager and volume manager are separate and distinct from one another 
per the teachings of McMichael. 

Nor do the teachings of the cited Gao reference overcome such teaching/suggestion 
deficiency. Gao does not describe any type of logical volume manager, and thus it necessarily 
follows that it cannot teach or otherwise suggest adding a new device type to a metadata within a 
(missing) logical volume manager. Therefore, the Examiner has failed to properly establish a 
prima facie showing of obviousness with respect to Claim 1, as there are claimed features not 
taught or suggested by the cited art. 

Further with respect to Claim 1, it is urged that none of the cited references teach or 
suggest the claimed feature of "adding a new device with the new device type to a kernel space". 
As can be seen, a new device with the new device type (which was set for the logical volume, in 
the "setting a new device type for the logical volume" step) is added to a kernel space. In 
rejecting this aspect of Claim 1, the Examiner cites McMichael's teaching at page 5, paragraph 
55 as teaching this claimed feature. Appellants urge that this cited McMichael passage states: 

[0055] In this section of the detailed description, a particular implementation of 
the invention is described that executes as part of the Microsoft Windows NT 5.0 
operating system kernel. In the implementation illustrated in FIG. 4, the partition 
manager 401 and four other kernel modules work together to provide a user with 
access to data stored on a physical storage device 413 (shown as a fixed hard 
disk): a plug and play manager 405, an object manager 407, a mount manager 
409, and two volume managers 41 1, 412. As will be readily apparent to one 
skilled in the art, the allocation of functions among the modules can be modified 
without exceeding the scope of the invention. 
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As can be seen, this passage merely describes that the invention executes as part of the operating 
system kernel, where the partition manager and four other kernel modules work together to 
provide a user with access to data stored on a physical storage device. There is no specific 
teaching or suggestion as to any type of new device being added with the new device type (which 
was set for the logical volume, in the "setting a new device type for the logical volume" step), 
either to the kernel space (as claimed) or otherwise. As this is the sole passage that is cited as 
teaching the claimed 'adding' step, it is urged that the Examiner has failed to properly establish a 
prima facie showing of obviousness with respect to Claim l 2 . Accordingly, the burden has not 
shifted to Appellants to rebut such improper obviousness assertion 3 . In addition, as a proper 
prima facie showing of obviousness has not been established, Claim 1 has been erroneously 
rejected 4 . 

Still further with respect to Claim 1, it is urged that the cited McMichael and Gao 
references are non-analogous art - one (McMichael) being directed to a storage disk partitioning 
scheme and the other (Gao) being directed to a snoop utility used for monitoring communication 
networks. The combination of elements from non analogous sources, in a manner that 
reconstructs the applicant's invention only with the benefit of hindsight, is insufficient to present 
a prima facie case of obviousness. In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 
1992). Thus, Claim 1 is further shown to have been erroneously rejected under 35 U.S.C. § 103 
using non-analogous art. 

C.2. Claims 2 and 13 

Appellants initially show error in the rejection of Claim 2 (and similarly for Claim 13) for 
reasons given above with respect to Claim 1 (of which Claim 2 depends upon). 

Further with respect to Claim 2, Appellants show error in the rejection of such claim in 
that none of the cited references teach or suggest the claimed feature of "supplying the logical 
volume manager with a new device type for the logical volume". As can be seen, the logical 
volume manager is supplied with a new device type for the logical volume. In rejecting Claim 2, 
the Examiner cites Gao's pages 2-3 as describing a snoop utility that can issue an ioctl call to 



2 MPEP 2143.03. See also, In re Royka, 490 F.2d 580 (C.C.P.A. 1974). 

3 In re Oetiker, supra. 

4 In re Fine, supra. 
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obtain in detail more configuration information corresponding to the device driver's media type 
(e.g. Ethernet). Appellants urge that such determination with respect to a data communication 
network's media type is not in any way related to any type of logical volume or logical volume 
manager, and thus this cited passage does not teach or otherwise suggest the specific claimed 
feature of "supplying the logical volume manager with a new device type for the logical volume" 
(emphasis added by Appellants). Thus, Claim 2 is further shown to have been erroneously 
rejected as there are additional claimed features not taught or suggested by the cited references 
and therefore a proper prima facie case of obviousness has not been established by the Examiner. 

C.3. Claims 3 and 14 

Appellants initially show error in the rejection of Claim 3 (and similarly for Claim 14) for 
reasons given above with respect to Claim 1 (of which Claim 3 depends upon). 

Further with respect to Claim 3 (and similarly for Claim 14), Appellants show error in the 
rejection of such claim in that none of the cited references teach or suggest the claimed feature of 
"using the new device type to indicate to the application that the application may perform a 
particular behavior defined by the new device type". In rejecting Claim 3, the Examiner cites 
Gao's teaching at page 3, paragraph 19 as teaching that if the media type is Ethernet, the snoop 
utility operates accordingly. Appellants urge that Claim 3 goes well beyond such assertion, and 
is specifically directed to a particular use of the new device type that was set for the logical 
volume . As the cited Gao reference is not directed in any way to any type of logical volume, it 
necessarily follows that the cited Gao reference does not teach any new device type for such 
(missing) logical volume, and because Gao does not teach/suggest any such new device type, it 
necessarily follows that there is no teaching of any particular usage of such (missing) new device 
type - and in particular there is no teaching/suggestion of using the (missing) new device type to 
indicate to the application that the application may perform a particular behavior defined by the 
new device type. Thus, Claim 3 is further shown to have been erroneously rejected as there are 
additional claimed features not taught or suggested by the cited references and therefore a proper 
prima facie case of obviousness has not been established by the Examiner. 
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C.4. Claim 6 

Appellants initially show error in the rejection of Claim 6 for reasons given above with 
respect to Claim 3 (of which Claim 6 depends upon). 

Further with respect to Claim 6, Appellants show error in the rejection of such claim in 
that none of the cited references teach or suggest the claimed feature of "wherein the particular 
behavior defined by the new device type includes allowing the application to enable a new 
feature within the application". In rejecting Claim 6, the Examiner cites Gao's teaching at page 
4, example 1 with respect to PPP_EPV6. Appellants urge that this cited passage describes a data 
structure used to describe a communication protocol to a data link user (page 4, paragraph 0043), 
and has nothing to do with a new device type for a logical volume. Therefore, this cited passage 
does not teach/suggest "wherein the particular behavior defined by the new device type includes 
allowing the application to enable a new feature within the application" (emphasis added by 
Appellants). Thus, Claim 6 is further shown to have been erroneously rejected as there are 
additional claimed features not taught or suggested by the cited references and therefore a proper 
prima facie case of obviousness has not been established by the Examiner. 

C.5. Claim 7 

Appellants initially show error in the rejection of Claim 7 for reasons given above with 
respect to Claim 3 (of which Claim 7 depends upon). 

Further with respect to Claim 7, Appellants show error in the rejection of such claim in 
that none of the cited references teach or suggest the claimed feature of "wherein the particular 
behavior defined by the new device type includes allowing the application to reduce a currently 
supported feature set within the application". In rejecting Claim 7, the Examiner cites Gao's 
teaching at page 4, example 1 with respect to PPP_IP. Appellants urge that this cited passage 
describes a data structure used to describe a communication protocol to a data link user (page 4, 
paragraph 0043), and has nothing to do with a new device type for a logical volume. Therefore, 
this cited passage does not teach/suggest "wherein the particular behavior defined by the new 
device type includes allowing the application to reduce a currently supported feature set within 
the application" (emphasis added by Appellants). Thus, Claim 7 is further shown to have been 
erroneously rejected as there are additional claimed features not taught or suggested by the cited 
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references and therefore a proper prima facie case of obviousness has not been established by the 
Examiner. 

C.6. Claim 8 

Appellants initially show error in the rejection of Claim 8 for reasons given above with 
respect to Claim 3 (of which Claim 8 depends upon). 

Further with respect to Claim 8, Appellants show error in the rejection of such claim in 
that none of the cited references teach or suggest the claimed feature of "wherein the particular 
behavior defined by the new device type includes allowing the application to prevent older 
versions of the application from using the logical volume". In rejecting Claim 8, the Examiner 
states that such claim is rejected 'based on the same rationale as in the rejection of claims 6-7', in 
that a user can select to apply new version of Ethernet protocol over an old version. Appellants 
urge that such assertion does not establish any teaching or suggestion with respect to (1) the 
particular use of the new device type (for the logical volume), or (2) the prevention of older 
versions of an application from using a logical volume manager. Claim 8 expressly recites 
"wherein the particular behavior defined by the new device type includes allowing the application 
to prevent older versions of the application from using the logical volume" (emphasis added by 
Appellants). Thus, Claim 8 is further shown to have been erroneously rejected as there are 
additional claimed features not taught or suggested by the cited references and therefore a proper 
prima facie case of obviousness has not been established by the Examiner. 

C.7. Claim 9 

Appellants initially traverse the rejection of Claim 9 for reasons given above with respect 
to Claim 3 (of which Claim 9 depends upon). 

Further with respect to Claim 9, Appellants show error in the rejection of such claim in 
that none of the cited references teach or suggest the claimed feature of "wherein the particular 
behavior defined by the new device type includes allowing the application to test the 
application's expected behavior on a different volume manager". In rejecting Claim 9, the 
Examiner states that such claim is rejected 'based on the same rationale as in the rejection of 
claims 2-3'. Appellants urge that such assertion does not establish any teaching or suggestion 
with respect to (1) a defined behavior that allows testing of an application's expected behavior, 
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or (2) using a different volume manager for such allowed test. Claim 9 expressly recites 
"wherein the particular behavior defined by the new device type includes allowing the 
application to test the application's expected behavior on a different volume manage r" 
(emphasis added by Appellants). Thus, Claim 9 is further shown to have been erroneously 
rejected as a proper prima facie case of obviousness has not been established by the Examiner. 

C.8. Claim 11 

With respect to Claim 11, Appellants show error in the rejection of such claim in that 
none of the cited references teach or suggest the claimed feature of "wherein the new device type 
set for the logical volume is used to indicate to the application that the application may perform a 
particular behavior defined by the new device type'" (emphasis added by Appellants). In 
rejecting Claim 1 1, the Examiner states such claim is rejected 'based on the same rationale as in 
the rejection of claim 1'. Appellants urge that since Claim 1 does not recite any use of the new 
device type - including using the new device type to indicate something to an application - the 
Examiner has failed to establish any teaching or suggestion of the claimed feature of "wherein 
the new device type set for the logical volume is used to indicate to the application that the 
application may perform a particular behavior defined by the new device type 1 '' (emphasis 
added). Thus, Claim 1 1 is shown to have been erroneously rejected as there are claimed features 
not taught or suggested, or even alleged to be taught or suggested, by the cited references. 

Still further with respect to Claim 11, it should be noted that in rejecting Claim 1 (the 
reasoning given in rejecting such claim being the sole reasoning given in rejecting Claim 1 1), the 
Examiner equates McMichael's description of enumerating volume device objects that are stored 
by device name as being equivalent to the claimed feature of setting a new device type for the 
logical volume. Appellants urge that the McMichael device names (e.g. VI and V2 as shown at 
elements 429 and 430 of McMichael's Figure 4) do not provide or convey any type of 
information indicating to an application that the application may perform a particular behavior 
defined by such device name. Rather, this McMichael device name is merely guaranteed to be 
unique during a boot session (page 6, paragraph 0060), and thus it is further urged that Claim 1 1 
is not obvious in view of the cited references as there are missing claimed features not taught or 
suggested by the cited references and therefore a proper prima facie case of obviousness has not 
been established by the Examiner. 
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C.9. Claim 16 

With respect to Claim 16, the sole basis given by the Examiner in finally rejecting such 
claim was "Claim 16 rejected based on the same rationale as in the rejection of claim 6". 
Appellants urge that Claim 16 is different from Claim 6, and thus merely relying on the rationale 
used in rejecting Claim 6 as the sole basis of reasoning in rejecting Claim 16 is clearly erroneous 
as the Examiner has failed to establish a prima facie showing of obviousness with respect to 
Claim 16. Specifically, Claim 16 recites: 

16. The data processing system of claim 15, wherein the location to begin 
writing data in the database includes block zero of the logical volume control 
block. 

whereas Claim 6 recites: 

6. The method of claim 3, wherein the particular behavior defined by the new 
device type includes allowing the application to enable a new feature within the 
application. 

As can be seen, Claim 16 is directed to a location of where to begin writing data, whereas Claim 
6 is directed to a particular behavior defined by the new device type. These are different claimed 
features. Thus, a mere reliance on an alleged teaching of a particular behavior defined by a new 
device type (as per Claim 6) does not allege or otherwise establish any teaching or suggestion in 
the cited references to the claimed feature directed to a location of where to begin writing data 
(as per Claim 16). Thus, the Examiner has failed to properly establish a prima facie showing of 
obviousness with respect to Claim 16, and accordingly the burden has not shifted to Appellants 
to rebut the (improper) obviousness assertion. In addition, as a prima facie case of obviousness 
has not been established, Claim 16 has been erroneously rejected. 

This erroneous rejection of Claim 16, by mere reliance on the reasoning given in rejecting 
Claim 6, is further shown in that Claim 16 depends upon Claim 15, which recites: 
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15. The data processing system of claim 14, wherein the particular behavior 
defined by the new device type includes allowing the application to determine a 
location to begin writing data in a database. 

The Examiner has made no allegation, in the current rejection of Claim 16 (which depends upon 
this Claim 15), as to any teaching or suggestion in either the cited McMichael reference or the 
cited Gao reference, of any of the claimed features recited in Claim 15 (of which Claim 16 
depends upon). Thus, it is further shown that the Examiner has failed to properly establish a 
prima facie showing of obviousness with respect to Claim 16, and thus such claim has been 
erroneously rejected under 35U.S.C.§103. 

C.10. Claim 17 

With respect to Claim 17, the sole basis given by the Examiner in finally rejecting such 
claim was "Claim 17 rejected based on the same rationale as in the rejection of claim 7". 
Appellants urge that Claim 17 is different from Claim 7, and thus merely relying on the rationale 
used in rejecting Claim 7 as the sole basis in rejecting Claim 17 is clearly erroneous as the 
Examiner has failed to establish a prima facie showing of obviousness with respect to Claim 17. 
Specifically, Claim 17 recites: 

17. The data processing system of claim 14, wherein the particular behavior 
defined by the new device type includes allowing the application to enable a new 
feature within the application. 

whereas Claim 7 recites: 

7. The method of claim 3, wherein the particular behavior defined by the new 
device type includes allowing the application to reduce a currently supported 
feature set within the application. 

As can be seen, Claim 17 is directed to particular behavior defined by the new device type that 
includes allowing the application to enable a new feature within the application, whereas Claim 
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7 is directed to a particular behavior defined by the new device type that includes allowing the 
application to reduce a currently supported feature set within the application. These are 
different claimed features. Thus, a mere reliance on an alleged teaching of a particular behavior 
defined by a new device type that includes allowing the application to reduce a currently 
supported feature set within the application (as per Claim 7) does not allege or otherwise 
establish any teaching or suggestion in the cited references to the claimed feature directed to a 
particular behavior defined by the new device type that includes allowing the application to 
enable a new feature within the application (as per Claim 17). Thus, the Examiner has failed to 
properly establish a prima facie showing of obviousness with respect to Claim 17, and 
accordingly the burden has not shifted to Appellants to rebut the (improper) obviousness 
assertion. In addition, as a prima facie case of obviousness has not been established, Claim 17 
has been erroneously rejected. 

Gil. Claim 18 

With respect to Claim 18, the sole basis given by the Examiner in finally rejecting such 
claim was "Claim 18 rejected based on the same rationale as in the rejection of claim 8". 
Appellants urge that Claim 18 is different from Claim 8, and thus merely relying on the rationale 
used in rejecting Claim 8 as the sole basis in rejecting Claim 18 is clearly erroneous as the 
Examiner has failed to establish a prima facie showing of obviousness with respect to Claim 18. 
Specifically, Claim 18 recites: 

18. The data processing system of claim 14, wherein the particular behavior 
defined by the new device type includes allowing the application to reduce a 
currently supported feature set within the application. 

whereas Claim 8 recites: 

8. The method of claim 3, wherein the particular behavior defined by the new 
device type includes allowing the application to prevent older versions of the 
application from using the logical volume 



Page 22 of 35 
McBrearty- 10/674,976 



As can be seen, Claim 18 is directed to a particular behavior defined by the new device type that 
includes allowing the application to reduce a currently supported feature set within the 
application, whereas Claim 8 is directed a particular behavior defined by the new device type 
that includes allowing the application to prevent older versions of the application from using the 
logical volume. These are different claimed features. Thus, a mere reliance on an alleged 
teaching of a particular behavior defined by a new device type that includes allowing the 
application to prevent older versions of the application from using the logical volume (as per 
Claim 8) does not allege or otherwise establish any teaching or suggestion in the cited references 
to the claimed feature directed to a particular behavior defined by the new device type that 
includes allowing the application to reduce a currently supported feature set within the 
application (as per Claim 18). Thus, the Examiner has failed to properly establish a prima facie 
showing of obviousness with respect to Claim 18, and accordingly the burden has not shifted to 
Appellants to rebut the (improper) obviousness assertion. In addition, as a prima facie case of 
obviousness has not been established, Claim 1 8 has been erroneously rejected. 

C.12. Claim 19 

With respect to Claim 19, the sole basis given by the Examiner in finally rejecting such 
claim was "Claim 19 rejected based on the same rationale as in the rejection of claim 9". 
Appellants urge that Claim 19 is different from Claim 9, and thus merely relying on the rationale 
used in rejecting Claim 9 as the sole basis in rejecting Claim 19 is clearly erroneous as the 
Examiner has failed to establish a prima facie showing of obviousness with respect to Claim 19. 
Specifically, Claim 19 recites: 

19. The data processing system of claim 14, wherein the particular behavior 
defined by the new device type includes allowing the application to prevent older 
versions of the application from using the logical volume. 

whereas Claim 9 recites: 



Page 23 of 35 
McBrearty- 10/674,976 



9. The method of claim 3, wherein the particular behavior defined by the new 
device type includes allowing the application to test the application's expected 
behavior on a different volume manager. 

As can be seen, Claim 19 is directed to a particular behavior defined by the new device type that 
includes allowing the application to prevent older versions of the application from using the 
logical volume, whereas Claim 9 is directed to particular behavior defined by the new device type 
that includes allowing the application to test the application 's expected behavior on a different 
volume manager. These are different claimed features. Thus, a mere reliance on an alleged 
teaching of a particular behavior defined by a new device type that includes allowing the 
application to test the application's expected behavior on a different volume manager (as per 
Claim 9) does not allege or otherwise establish any teaching or suggestion in the cited references 
to the claimed feature directed to a particular behavior defined by the new device type that 
includes allowing the application to prevent older versions of the application from using the 
logical volume (as per Claim 19). Thus, the Examiner has failed to properly establish a prima 
facie showing of obviousness with respect to Claim 19, and accordingly the burden has not 
shifted to Appellants to rebut the (improper) obviousness assertion. In addition, as a prima facie 
case of obviousness has not been established, Claim 19 has been erroneously rejected. 

C.13. Claim 20 

With respect to Claim 20, the sole basis given by the Examiner in finally rejecting such 
claim was "Claim 20 rejected based on the same rationale as in the rejection of claim 10". 
Appellants urge that Claim 20 is different from Claim 10, and thus merely relying on the 
rationale used in rejecting Claim 10 as the sole basis in rejecting Claim 20 is clearly erroneous as 
the Examiner has failed to establish a prima facie showing of obviousness with respect to Claim 
20. Specifically, Claim 20 recites: 

20. The data processing system of claim 14, wherein the particular behavior 
defined by the new device type includes allowing the application to test the 
application's expected behavior on a different volume manager. 
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whereas Claim 10 recites: 



10. The method of claim 1, wherein the new device type set for the logical 
volume is non-changeable for the life of the logical volume. 

As can be seen, Claim 20 is directed to a particular behavior defined by the new device type that 
includes allowing the application to test the application 's expected behavior on a different 
volume manager, whereas Claim 10 is directed to a new device type that is non-changeable. 
These are different claimed features. Thus, a mere reliance on an alleged teaching of a new 
device type set for the logical volume that is non-changeable for the life of the logical volume (as 
per Claim 10) does not allege or otherwise establish any teaching or suggestion in the cited 
references to the claimed feature directed to a particular behavior defined by the new device type 
that includes allowing the application to test the application 's expected behavior on a different 
volume manager (as per Claim 20). Thus, the Examiner has failed to properly establish a prima 
facie showing of obviousness with respect to Claim 20, and accordingly the burden has not 
shifted to Appellants to rebut the (improper) obviousness assertion. In addition, as a prima facie 
case of obviousness has not been established, Claim 20 has been erroneously rejected. 

D. GROUND OF REJECTION 4 (Claims 4-5 and 15) 

D.l. Claims 4 and 15 

With respect to Claim 4 (and similarly for Claim 15), Appellants initially show error in 
the rejection of such claim for similar reasons to those given above with respect to Claim 3 (of 
which Claim 4 depends upon), as (i) none of the cited references teach or suggest the claimed 
features identified above with respect to Claim 3 and (ii) the cited Gao reference is non- 
analogous art. 

Further with respect to Claim 4, Appellants show error in the rejection of such claim in 
that none of the cited references teach or suggest the claimed feature of "wherein the particular 
behavior defined by the new device type includes allowing the application to determine a location 
to begin writing data in a database" (emphasis added). In rejecting Claim 4, the Examiner states 
that such claimed feature is taught by Irwin at col. 17, lines 1-7. Appellants urge that this Irwin 
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passage describes personality modules that are used to (i) translate the device driver's entry point 
block I/O functions into specific storage device I/O commands, and (ii) interpret status 
information received from the storage device. There is no mention of (i) a device type for a 
logical volume that defines a particular behavior, or (ii) allowing an application to determine a 
location to begin writing data in a database. Thus, the Examiner has failed to properly establish a 
prima facie showing of obviousness with respect to Claim 4, and accordingly the burden has not 
shifted to Appellants to rebut the (improper) obviousness assertion. In addition, as a prima facie 
case of obviousness has not been established, Claim 4 has been erroneously rejected. 

D.2. Claim 5 

With respect to Claim 5, Appellants initially show error in the rejection of such claim for 
similar reasons to those given above with respect to Claim 4 (of which Claim 5 depends upon). 

Further with respect to Claim 5, Appellants show error in the rejection of such claim in 
that none of the cited references teach or suggest the claimed feature of "wherein the location to 
begin writing data in the database includes block zero of the logical volume control block". In 
rejecting Claim 5, the Examiner states that McMichael teaches this claimed feature at page 4, 
paragraphs 37 and 42; page 5, paragraphs 47-48; and page 1, paragraphs 5-10. Appellants have 
reviewed each of these passages extensively, and can find no mention of any type of logical 
volume control block, and thus there is no teaching/suggestion in these cited passages of 
"wherein the location to begin writing data in the database includes block zero of the logical 
volume control block". Claim 5 is thus further shown to have been erroneously rejected as there 
are additional claimed features not taught or suggested by the cited references. 

Still further with respect to Claim 5, such claim depends upon Claim 4 and is a further 
refinement to the claimed location determination recited in Claim 4. As this location 
determination is alleged to be taught by the cited Irwin reference (per the Claim 4 rejection), it is 
not possible for the cited McMichael reference to teach a further refinement to the location 
determination alleged to be taught by Irvin as they are different, and unrelated, references. Also, 
as McMichael does not teach any type of location determination being allowed by an application, 
it necessarily follows that McMichael' s does not teach the specifics of such location 
determination as expressly recited in Claim 5. Claim 5 is thus further shown to have been 
erroneously rejected as there are additional claimed features not taught or suggested by the cited 
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references and therefore a proper prima facie case of obviousness has not been established by the 
Examiner. 

In conclusion, Appellants have shown numerous and substantial errors in the final 
rejection of all pending claims, and respectfully requests that the Board reverse such final 
rejection. 



/Wayne P. Bailey/ 
Wayne P. Bailey 
Reg. No. 34,289 
Yee & Associates, P.C. 

PO Box 802333 
Dallas, TX 75380 
(972) 385-8777 
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CLAIMS APPENDIX 



The text of the claims involved in the appeal are: 

1 . A method for controlling the behavior of an application when storing data using a logical 
volume manager, comprising: 

creating a logical volume; 

setting a new device type for the logical volume, wherein the new device type is added to 
a metadata within the logical volume manager; and 

adding a new device with the new device type to a kernel space. 

2. The method of claim 1, wherein the step of creating the logical volume includes 
supplying the logical volume manager with a new device type for the logical volume. 

3. The method of claim 1, further comprising: 

using the new device type to indicate to the application that the application may perform a 
particular behavior defined by the new device type. 

4. The method of claim 3, wherein the particular behavior defined by the new device type 
includes allowing the application to determine a location to begin writing data in a database. 

5. The method of claim 4, wherein the location to begin writing data in the database 
includes block zero of the logical volume control block. 
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6. The method of claim 3, wherein the particular behavior defined by the new device type 
includes allowing the application to enable a new feature within the application. 

7. The method of claim 3, wherein the particular behavior defined by the new device type 
includes allowing the application to reduce a currently supported feature set within the 
application. 

8. The method of claim 3, wherein the particular behavior defined by the new device type 
includes allowing the application to prevent older versions of the application from using the 
logical volume. 

9. The method of claim 3, wherein the particular behavior defined by the new device type 
includes allowing the application to test the application's expected behavior on a different 
volume manager. 

10. The method of claim 1, wherein the new device type set for the logical volume is non- 
changeable for the life of the logical volume. 

11. A system for controlling the behavior of an application when storing data using a logical 
volume manager, comprising: 

a logical volume; 

a new device type set for the logical volume; and 
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an application, wherein the new device type set for the logical volume is used to indicate 
to the application that the application may perform a particular behavior defined by the new 
device type. 

12. A data processing system for controlling the behavior of an application when storing data 
using a logical volume manager, comprising: 

creating means for creating a logical volume; 

setting means for setting a new device type for the logical volume, wherein the setting 
step includes adding the new device type to a metadata within the logical volume manager; and 
adding means for adding a new device with the new device type to a kernel space. 

13. The data processing system of claim 12, wherein the creating means supplies the logical 
volume manager with a new device type for the logical volume. 

14. The data processing system of claim 12, further comprising: 

using means for using the new device type to indicate to the application that the 
application may perform a particular behavior defined by the new device type. 

15. The data processing system of claim 14, wherein the particular behavior defined by the 
new device type includes allowing the application to determine a location to begin writing data in 
a database. 
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16. The data processing system of claim 15, wherein the location to begin writing data in the 
database includes block zero of the logical volume control block. 

17. The data processing system of claim 14, wherein the particular behavior defined by the 
new device type includes allowing the application to enable a new feature within the application. 

18. The data processing system of claim 14, wherein the particular behavior defined by the 
new device type includes allowing the application to reduce a currently supported feature set 
within the application. 

19. The data processing system of claim 14, wherein the particular behavior defined by the 
new device type includes allowing the application to prevent older versions of the application 
from using the logical volume. 

20. The data processing system of claim 14, wherein the particular behavior defined by the 
new device type includes allowing the application to test the application's expected behavior on a 
different volume manager. 

21 . A computer program product tangibly embodied in a tangible computer readable medium 
for controlling the behavior of an application when storing data using a logical volume manager, 
comprising: 
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first instructions for creating a logical volume; 

second instructions for setting a new device type for the logical volume, wherein the 
setting step includes adding the new device type to a metadata within the logical volume 
manager; and 

third instructions for adding a new device with the new device type to a kernel space. 

22. The computer program product of claim 21, wherein the first instructions include 
instructions for supplying the logical volume manager with a new device type for the logical 
volume. 

23. The computer program product of claim 21, further comprising: 

fourth instructions for using the new device type to indicate to the application that the 
application may perform a particular behavior defined by the new device type. 

24. The computer program product of claim 23, wherein the particular behavior defined by 
the new device type includes allowing the application to determine a location to begin writing 
data in a database. 

25. The computer program product of claim 24, wherein the location to begin writing data in 
the database includes block zero of the logical volume control block. 
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26. The computer program product of claim 25, wherein the particular behavior defined by 
the new device type includes allowing the application to enable a new feature within the 
application. 

27. The computer program product of claim 25, wherein the particular behavior defined by 
the new device type includes allowing the application to reduce a currently supported feature set 
within the application. 

28. The computer program product of claim 25, wherein the particular behavior defined by 
the new device type includes allowing the application to prevent older versions of the application 
from using the logical volume. 

29. The computer program product of claim 25, wherein the particular behavior defined by 
the new device type includes allowing the application to test the application's expected behavior 
on a different volume manager. 
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EVIDENCE APPENDIX 

There is no evidence to be presented. 
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RELATED PROCEEDINGS APPENDIX 

There are no related proceedings. 
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